Block-level single instancing

ABSTRACT

Described in detail herein are systems and methods for single instancing blocks of data in a data storage system. For example, the data storage system may include multiple computing devices (e.g., client computing devices) that store primary data. The data storage system may also include a secondary storage computing device, a single instance database, and one or more storage devices that store copies of the primary data (e.g., secondary copies, tertiary copies, etc.). The secondary storage computing device receives blocks of data from the computing devices and accesses the single instance database to determine whether the blocks of data are unique (meaning that no instances of the blocks of data are stored on the storage devices). If a block of data is unique, the single instance database stores it on a storage device. If not, the secondary storage computing device can avoid storing the block of data on the storage devices.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.14/049,463 filed on Oct. 9, 2013 (entitled BLOCK-LEVEL SINGLEINSTANCING, Attorney Docket No. 060692-8073.US02) which is acontinuation of U.S. patent application Ser. No. 12/647,906 filed onDec. 28, 2009 (entitled BLOCK-LEVEL SINGLE INSTANCING, Attorney DocketNo. 060692-8073.US01), now U.S. Pat. No. 8,578,120, which claims thebenefit of U.S. Patent Application No. 61/180,791 filed on May 22, 2009(entitled BLOCK-LEVEL SINGLE INSTANCING, Attorney Docket No.060692-8073.US00), and is related to U.S. patent application Ser. No.12/565,576 filed on Sep. 23, 2009 (entitled SYSTEMS AND METHODS FORMANAGING SINGLE INSTANCING DATA, Attorney Docket No. 060692-8067.US01),each of which is incorporated by reference in its entirety.

BACKGROUND

Single instancing in a data storage system typically involves attemptingto store only a single instance of a file on a storage device. Incertain single instancing systems, a separate folder on the file systemof the storage device is created for each single instancing storageoperation performed. Each file that has been single instanced is storedas a separate individual file in the separate folder.

Because there may be numerous computing systems in the data storagesystem, each requiring one or more storage operations, these techniquesmay result in the creation of numerous folders, each containing numerousfiles. For example, if there are hundreds of computing systems, eachhaving thousands of files, backing up or copying all of these files maypotentially result in the creation of millions of files on the storagedevice.

Certain file systems of storage devices may not be capable of adequatelyproviding for storing such large numbers of files. Other file systemsmay be equipped to handle storing millions of files or more, but may notperform optimally in such situations.

The need exists for systems and methods that overcome the aboveproblems, as well as that provide additional benefits. Overall, theexamples herein of some prior or related systems and their associatedlimitations are intended to be illustrative and not exclusive. Otherlimitations of existing or prior systems will become apparent to thoseof skill in the art upon reading the following Detailed Description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example of a data storageenterprise that may employ aspects of the invention.

FIG. 2 is a block diagram depicting in more detail certain componentsillustrated in FIG. 1.

FIG. 3 is a flow diagram of certain aspects of a process for performinga storage operation.

FIG. 4 is a flow diagram of other aspects of a process for performing astorage operation.

FIGS. 5A and 5B are diagrams illustrating suitable data structures thatmay be employed by aspects of the invention.

FIGS. 6A and 6B are diagrams illustrating suitable data structures thatmay be employed by aspects of the invention.

FIG. 7 is a diagram illustrating various data structures that aspects ofthe invention may utilize.

FIG. 8 is a flow diagram of a process for restoring data.

FIG. 9 is a flow diagram of a process for pruning data.

DETAILED DESCRIPTION

The headings provided herein are for convenience only and do notnecessarily affect the scope or meaning of the claimed invention.

Overview

This application describes in detail, among other things, systems andmethods for single instancing (alternatively called deduplicating)blocks of data in a data storage system (alternatively called a datastorage network, a data storage environment, or a data storageenterprise). The data storage system stores single instanced blocks ofdata (alternatively referred to as deduplicated blocks of data) in oneor more files and maintains one or more data structures (e.g., indexfiles) that keep track of which blocks of data are referenced. Thisallows the data storage system to, among other things: 1)single-instance data at a more granular level (at a block-level insteadof at a file-level); 2) reduce or eliminate redundantly stored data,thereby saving storage space; 3) store very large numbers of blocks ofdata without regard to file system limitations; and 4) delete data thatno longer needs to be stored, while still maintaining data that needs tobe stored.

The data storage system, for example, may include multiple computingdevices or computing systems (e.g., client computing devices) that storeprimary data (e.g., production data such as system files, user files,etc.). The data storage system may also include a secondary storagecomputing device, a single instance database, and one or more storagedevices that store copies of the primary data (e.g., secondary copies,tertiary copies, etc.). The secondary storage computing device receivesblocks of data from the computing devices and accesses the singleinstance database to determine whether the blocks of data are unique(unique meaning that no instances of the blocks of data are alreadystored on the storage devices). If a block of data is unique, the singleinstance database stores it in a file on a storage device. If not, thesecondary storage computing device can avoid storing the block of dataon the storage devices.

The primary data of the computing devices can be divided into data thatis eligible for single instancing and data that is not eligible forsingle instancing. An example of the latter is metadata (e.g., MasterFile Table (MFT) information) and an example of the former is data(e.g., operating system and/or application files). A file typicallycomprises one or more blocks as tracked by the file systems of thecomputing devices.

The computing devices align data that is eligible for single instancinginto blocks of data (which may comprise one or more blocks as tracked bythe file systems of the computing devices) and generate identifiers forthe blocks of data that the secondary storage computing device uses todetermine if the blocks of data are unique. This allows the secondarystorage computing device to avoid generating identifiers for the blocksof data, which may be computationally expensive and/or require a longtime to perform. Therefore, the distribution of the task of generatingidentifiers (which can be computationally expensive operations) acrossnumerous computing devices frees up the secondary storage computingdevice to perform other operations (e.g., storing data, retrieving data,pruning data, etc.).

The computing devices send the blocks of data and other data (e.g.,metadata and/or the data that is not eligible for single instancing) ina data stream to the secondary storage computing device. The secondarystorage computing device receives the data stream and stores blocks ofdata and their identifiers in buffers in random access memory (RAM). Thesecondary storage computing device determines whether a block of data isalready stored on a storage device. To do this, the secondary storagecomputing device determines, by analyzing data structures in the singleinstance database in view of the block's identifier, whether the blockof data is already stored on a storage device. If it is, then thesecondary storage computing device 1) stores a link to the alreadystored block of data in a metadata file and 2) discards the block ofdata from the memory buffer. If it is not, then the secondary storagecomputing device stores the block of data in a container file.

Because the size of a block of data and associated metadata is typicallyless then the size of a memory buffer, the secondary storage computingdevice can keep a single block of data in a single memory buffer whileit looks up its identifier in the single instance database. This allowsthe secondary storage computing device to avoid writing the block ofdata to disk (an operation which is typically slower than storing theblock of data in a RAM buffer) until the secondary storage computingdevice determines that it needs to store the block of data in acontainer file on a storage device. The secondary storage computingdevice stores data that is not eligible for single instancing inmetadata files.

By storing multiple blocks of data in a single container file, thesecondary storage computing device avoids storing each block of data asa separate file on the file systems of the storage devices. This reducesthe number of files that would be stored on the file systems of thestorage devices, thereby ensuring that the storage devices canadequately store the data of the computing devices in the data storagesystem.

One advantage of these techniques is that they significantly reduce thenumber of files stored on a file system of a computing device or storagedevice. This is at least partly due to the storage of data blocks withinthe container files. Even if the secondary storage computing deviceperforms numerous storage operations, these techniques will result instoring far fewer files on the file system than storage operations whereeach data block is stored as a separate file. Therefore, the file systemof the computing device or storage device may not necessarily have tocontend with storing excessively large numbers of files, such asmillions of files or more. Accordingly, these techniques enable verylarge numbers of blocks of data to be stored without regard tolimitations of the file system of the computing device or storagedevice.

However, the storage of blocks of data in container files may createadditional complexities when it comes time to prune data. This isbecause a container file may contain blocks of data that are referencedby links in metadata files and thus cannot be deleted, becausereferenced blocks of data typically still need to be stored on thestorage devices. Furthermore, because the blocks of data are not storedas files on the file systems of the storage devices, they cannot bedirectly referenced by the file system.

The systems and methods described herein provide solutions to theseproblems. The secondary storage computing device creates the containerfiles as sparse files (typically only on operating systems that supportsparse files, e.g., Windows operating systems, and other operatingsystems that support sparse files). A sparse file is type of file thatmay include empty space (e.g., a sparse file may have real data withinit, such as at the beginning of the file and/or at the end of the file,but may also have empty space in it that is not storing actual data,such as a contiguous range of bytes all having a value of zero). Second,the secondary storage computing device maintains a separate index thatstores an indication of whether blocks of data in container files arereferred to by links in metadata files. In some examples, this can beanalogized to using another, non-native file system that keeps track ofblocks of data in the container files, on top of the existing, nativefile systems of the storage devices.

When a block of data is not referred to and does not need to be stored,the secondary storage computing device can prune it. To prune data, thesecondary storage computing device accesses the separate index todetermine the blocks of data that are not referred to by links. Onoperating systems that support sparse files, the secondary storagecomputing device can free up space in the container files correspondingto those blocks of data by marking the portions of the physical mediacorresponding to the unreferenced portions of the container file asavailable for storage (e.g., by zeroing out the corresponding bytes inthe container files). On operating systems that do not support sparsefiles, the secondary storage computing device can free up space in thecontainer files by truncating the extreme portions of the containerfiles (e.g., the extremities such as the beginnings and/or the ends ofthe container files), thereby making the corresponding portions of thephysical media available to store other data. Freeing up space incontainer files allows the operating system to utilize the freed-upspace in other fashions (e.g., other programs may utilize the freed-upspace).

Various examples of the invention will now be described. The followingdescription provides specific details for a thorough understanding andenabling description of these examples. One skilled in the relevant artwill understand, however, that the invention may be practiced withoutmany of these details. Likewise, one skilled in the relevant art willalso understand that the invention may include many other obviousfeatures not described in detail herein. Additionally, some well-knownstructures or functions may not be shown or described in detail below,so as to avoid unnecessarily obscuring the relevant description.

The terminology used below is to be interpreted in its broadestreasonable manner, even though it is being used in conjunction with adetailed description of certain specific examples of the invention.Indeed, certain terms may even be emphasized below; however, anyterminology intended to be interpreted in any restricted manner will beovertly and specifically defined as such in this Detailed Descriptionsection.

FIGS. 1 and 2 and the discussion herein provide a brief, generaldescription of a suitable specialized environment in which aspects ofthe invention can be implemented. Those skilled in the relevant art willappreciate that aspects of the invention can be practiced with othercommunications, data processing, or computer system configurations,including: Internet appliances, hand-held devices (including personaldigital assistants (PDAs)), wearable computers, all manner of cellularphones, mobile phones, and/or mobile devices, multi-processor systems,microprocessor-based or programmable consumer electronics, set-topboxes, network PCs, mini-computers, mainframe computers, and the like.The terms “computer,” “server,” “host,” “host system,” “client,” and thelike are generally used interchangeably herein, and refer to any of theabove devices and systems, as well as any data processor.

While aspects of the invention, such as certain functions, are describedas being performed exclusively on a single device, the invention canalso be practiced in distributed environments where functions or modulesare shared among disparate processing devices, which are linked througha communications network, such as a Local Area Network (LAN), Wide AreaNetwork (WAN), and/or the Internet. In a distributed computingenvironment, program modules may be located in both local and remotememory storage devices.

Aspects of the invention may be stored or distributed oncomputer-readable media, including tangible computer-readable storagemedia such as magnetically or optically readable computer discs,hard-wired or preprogrammed chips (e.g., EEPROM semiconductor chips),nanotechnology memory, biological memory, or other data storage media.Alternatively, computer implemented instructions, data structures,screen displays, and other data under aspects of the invention may bedistributed over the Internet or over other networks (including wirelessnetworks), on a propagated signal on a propagation medium (e.g., anelectromagnetic wave(s), a sound wave, etc.) over a period of time, orthey may be provided on any analog or digital network (packet switched,circuit switched, or other scheme).

Aspects of the invention will now be described in detail with respect toFIGS. 1 through 9. FIG. 1 illustrates an example of a data storagesystem that may employ aspects of the invention. FIG. 2 illustrates inmore detail certain components illustrated in FIG. 1 that may be used toimplement a block-level single instancing system. These componentsinclude a secondary storage computing device, a single instancingdatabase, and a storage device that stores only a single instance ofblocks of data of one or more computing devices (e.g., client computingdevices).

FIG. 3 illustrates aspects of a process for copying data that acomputing device (e.g., a client computing device) may perform. Theseaspects include determining whether data is eligible for singleinstancing and transferring data in a data stream to the secondarystorage computing device. FIG. 4 illustrates aspects of the copy processthat the secondary storage computing device may perform upon receipt ofthe data stream from the computing device. During this part of the copyprocess, the secondary storage computing device determines whether thedata of the computing device is single instanceable.

FIGS. 5A and 5B, 6A and 6B, and 7 are illustrations of various datastructures that aspects of the invention may utilize. FIGS. 5A and 5Bdepict data streams that the computing device may form during the copyprocess. FIGS. 6A and 6B show data structures that may be used by thesingle instance database to keep track of where blocks of data andreferences to blocks of data are stored on the storage device. FIG. 7illustrates data structures that may be used to store blocks of data onthe storage device.

FIGS. 8 and 9 are process flow diagrams. FIG. 8 illustrates an exampleprocess that the secondary storage computing device may perform torestore data stored on the storage device, such as to a computingdevice. FIG. 9 depicts an example process that the secondary storagecomputing device may perform to prune data stored on the storage devicewhen it is no longer required to be stored on the storage device.

Suitable Data Storage System

FIG. 1 illustrates an example of one arrangement of resources in acomputing network, comprising a data storage system 150. The resourcesin the data storage system 150 may employ the processes and techniquesdescribed herein. The system 150 includes a storage manager 105, one ormore data agents 195, one or more secondary storage computing devices165, one or more storage devices 115, one or more computing devices 130(called clients 130), one or more data or information stores 160 and162, and a single instancing database 123. The storage manager 105includes an index 111, a jobs agent 120, an interface agent 125, and amanagement agent 131. The system 150 may represent a modular storagesystem such as the CommVault QiNetix system, and also the CommVaultGALAXY backup system, available from CommVault Systems, Inc. ofOceanport, N.J., aspects of which are further described in thecommonly-assigned U.S. patent application Ser. No. 09/610,738, now U.S.Pat. No. 7,035,880, the entirety of which is incorporated by referenceherein. The system 150 may also represent a modular storage system suchas the CommVault Simpana system, also available from CommVault Systems,Inc.

The system 150 may generally include combinations of hardware andsoftware components associated with performing storage operations onelectronic data. Storage operations include copying, backing up,creating, storing, retrieving, and/or migrating primary storage data(e.g., data stores 160 and/or 162) and secondary storage data (which mayinclude, for example, snapshot copies, backup copies, hierarchicalstorage management (HSM) copies, archive copies, and other types ofcopies of electronic data stored on storage devices 115). The system 150may provide one or more integrated management consoles for users orsystem processes to interface with in order to perform certain storageoperations on electronic data as further described herein. Suchintegrated management consoles may be displayed at a central controlfacility or several similar consoles distributed throughout multiplenetwork locations to provide global or geographically specific networkdata storage information.

In one example, storage operations may be performed according to variousstorage preferences, for example, as expressed by a user preference, astorage policy, a schedule policy, and/or a retention policy. A “storagepolicy” is generally a data structure or other information source thatincludes a set of preferences and other storage criteria associated withperforming a storage operation. The preferences and storage criteria mayinclude, but are not limited to, a storage location, relationshipsbetween system components, network pathways to utilize in a storageoperation, data characteristics, compression or encryption requirements,preferred system components to utilize in a storage operation, a singleinstancing or variable instancing policy to apply to the data, and/orother criteria relating to a storage operation. For example, a storagepolicy may indicate that certain data is to be stored in the storagedevice 115, retained for a specified period of time before being aged toanother tier of secondary storage, copied to the storage device 115using a specified number of data streams, etc.

A “schedule policy” may specify a frequency with which to performstorage operations and a window of time within which to perform them.For example, a schedule policy may specify that a storage operation isto be performed every Saturday morning from 2:00 a.m. to 4:00 a.m. A“retention policy” may specify how long data is to be retained atspecific tiers of storage or what criteria must be met before data maybe pruned or moved from one tier of storage to another tier of storage.In some cases, the storage policy includes information generallyspecified by the schedule policy and/or the retention policy. (Putanother way, the storage policy includes the schedule policy and/or theretention policy.) Storage policies, schedule policies and/or retentionpolicies may be stored in a database of the storage manager 105, toarchive media as metadata for use in restore operations or other storageoperations, or to other locations or components of the system 150.

The system 150 may comprise a storage operation cell that is one ofmultiple storage operation cells arranged in a hierarchy or otherorganization. Storage operation cells may be related to backup cells andprovide some or all of the functionality of backup cells as described inthe assignee's U.S. patent application Ser. No. 09/354,058, now U.S.Pat. No. 7,395,282, which is incorporated herein by reference in itsentirety. However, storage operation cells may also perform additionaltypes of storage operations and other types of storage managementfunctions that are not generally offered by backup cells.

Storage operation cells may contain not only physical devices, but alsomay represent logical concepts, organizations, and hierarchies. Forexample, a first storage operation cell may be configured to perform afirst type of storage operations such as HSM operations, which mayinclude backup or other types of data migration, and may include avariety of physical components including a storage manager 105 (ormanagement agent 131), a secondary storage computing device 165, aclient 130, and other components as described herein. A second storageoperation cell may contain the same or similar physical components;however, it may be configured to perform a second type of storageoperations, such as storage resource management (SRM) operations, andmay include monitoring a primary data copy or performing other known SRMoperations.

Thus, as can be seen from the above, although the first and secondstorage operation cells are logically distinct entities configured toperform different management functions (i.e., HSM and SRM,respectively), each storage operation cell may contain the same orsimilar physical devices. Alternatively, different storage operationcells may contain some of the same physical devices and not others. Forexample, a storage operation cell configured to perform SRM tasks maycontain a secondary storage computing device 165, client 130, or othernetwork device connected to a primary storage volume, while a storageoperation cell configured to perform HSM tasks may instead include asecondary storage computing device 165, client 130, or other networkdevice connected to a secondary storage volume and not contain theelements or components associated with and including the primary storagevolume. (The term “connected” as used herein does not necessarilyrequire a physical connection; rather, it could refer to two devicesthat are operably coupled to each other, communicably coupled to eachother, in communication with each other, or more generally, refer to thecapability of two devices to communicate with each other.) These twostorage operation cells, however, may each include a different storagemanager 105 that coordinates storage operations via the same secondarystorage computing devices 165 and storage devices 115. This“overlapping” configuration allows storage resources to be accessed bymore than one storage manager 105, such that multiple paths exist toeach storage device 115 facilitating failover, load balancing, andpromoting robust data access via alternative routes.

Alternatively or additionally, the same storage manager 105 may controltwo or more storage operation cells (whether or not each storageoperation cell has its own dedicated storage manager 105). Moreover, incertain embodiments, the extent or type of overlap may be user-defined(through a control console) or may be automatically configured tooptimize data storage and/or retrieval.

The clients 130 typically include application software for performingvarious operations. Clients 130 typically also include an operatingsystem on which the application software runs. A file system can beprovided to facilitate and control file access by the operating systemand application software. File systems can facilitate access to localand remote storage devices for file or data access and storage. Clients130 can also include local storage such as a media module media drivewith fixed or removable media.

In some examples, the clients 130 include storage mechanisms forallowing computer programs or other instructions or data to be loadedinto memory for execution. Such storage mechanisms might include, forexample, a fixed or removable storage unit and an interface. Examples ofsuch storage units and interfaces can include a program cartridge andcartridge interface, a removable memory (for example, a flash memory orother removable memory module) and memory slot, a PCMCIA slot and card,and other fixed or removable storage units and interfaces that allowsoftware and data to be transferred from the storage unit to memory.

Data agent 195 may be a software module or part of a software modulethat is generally responsible for performing storage operations on thedata of the client 130 stored in data store 160/162 or other memorylocation. Each client 130 may have at least one data agent 195 and thesystem 150 can support multiple clients 130. Data agent 195 may bedistributed between client 130 and storage manager 105 (and any otherintermediate components), or it may be deployed from a remote locationor its functions approximated by a remote process that performs some orall of the functions of data agent 195.

As used herein, the term module might describe a given unit offunctionality that can be performed in accordance with one or moreembodiments of the present invention. As used herein, a module might beimplemented utilizing any form of hardware, software, firmware, or acombination thereof. For example, one or more processors, controllers,ASICs, PLAs, logical components, software routines or other mechanismsmight be implemented to make up a module. In implementation, the variousmodules described herein might be implemented as discrete modules or thefunctions and features described can be shared in part or in total amongone or more modules. In other words, as would be apparent to one ofordinary skill in the art after reading this description, the variousfeatures and functionality described herein may be implemented in anygiven application and can be implemented in one or more separate orshared modules in various combinations and permutations. Even thoughvarious features or elements of functionality may be individuallydescribed or claimed as separate modules, one of ordinary skill in theart will understand that these features and functionality can be sharedamong one or more common software and hardware elements, and suchdescription shall not require or imply that separate hardware orsoftware components are used to implement such features orfunctionality.

The overall system 150 may employ multiple data agents 195, each ofwhich may perform storage operations on data associated with a differentapplication. For example, different individual data agents 195 may bedesigned to handle Microsoft Exchange data, Lotus Notes data, MicrosoftWindows file system data, Microsoft Active Directory Objects data,Microsoft SQL Server data, Microsoft Sharepoint Server data, and othertypes of data known in the art. Other embodiments may employ one or moregeneric data agents 195 that can handle and process multiple data typesrather than using the specialized data agents described above.

If a client 130 has two or more types of data, one data agent 195 may berequired for each data type to perform storage operations on the data ofthe client 130. For example, to back up, migrate, and restore all thedata on a Microsoft Exchange server, the client 130 may use oneMicrosoft Exchange Mailbox data agent 195 to back up the Exchangemailboxes, one Microsoft Exchange Database data agent 195 to back up theExchange databases, one Microsoft Exchange Public Folder data agent 195to back up the Exchange Public Folders, and one Microsoft Windows FileSystem data agent 195 to back up the file system of the client 130.These data agents 195 would be treated as four separate data agents 195by the system even though they reside on the same client 130.

Alternatively, the overall system 150 may use one or more generic dataagents 195, each of which may be capable of handling two or more datatypes. For example, one generic data agent 195 may be used to back up,migrate and restore Microsoft Exchange Mailbox data and MicrosoftExchange Database data while another generic data agent 195 may handleMicrosoft Exchange Public Folder data and Microsoft Windows File Systemdata, etc.

Data agents 195 may be responsible for arranging or packing data to becopied or migrated into a certain format such as an archive file.Nonetheless, it will be understood that this represents only oneexample, and any suitable packing or containerization technique ortransfer methodology may be used if desired. Such an archive file mayinclude metadata, a list of files or data objects copied, the file, anddata objects themselves. Moreover, any data moved by the data agents maybe tracked within the system by updating indexes associated withappropriate storage managers 105 or secondary storage computing devices165. As used herein, a file or a data object refers to any collection orgrouping of bytes of data that can be viewed as one or more logicalunits.

Generally speaking, storage manager 105 may be a software module orother application that coordinates and controls storage operationsperformed by the system 150. Storage manager 105 may communicate withsome or all elements of the system 150, including clients 130, dataagents 195, secondary storage computing devices 165, and storage devices115, to initiate and manage storage operations (e.g., backups,migrations, data recovery operations, etc.).

Storage manager 105 may include a jobs agent 120 that monitors thestatus of some or all storage operations previously performed, currentlybeing performed, or scheduled to be performed by the system 150. (One ormore storage operations are alternatively referred to herein as a “job”or “jobs.”) Jobs agent 120 may be communicatively coupled to aninterface agent 125 (e.g., a software module or application). Interfaceagent 125 may include information processing and display software, suchas a graphical user interface (“GUI”), an application programminginterface (“API”), or other interactive interface through which usersand system processes can retrieve information about the status ofstorage operations. For example, in an arrangement of multiple storageoperations cell, through interface agent 125, users may optionally issueinstructions to various storage operation cells regarding performance ofthe storage operations as described and contemplated herein. Forexample, a user may modify a schedule concerning the number of pendingsnapshot copies or other types of copies scheduled as needed to suitparticular needs or requirements. As another example, a user may employthe GUI to view the status of pending storage operations in some or allof the storage operation cells in a given network or to monitor thestatus of certain components in a particular storage operation cell(e.g., the amount of storage capacity left in a particular storagedevice 115).

Storage manager 105 may also include a management agent 131 that istypically implemented as a software module or application program. Ingeneral, management agent 131 provides an interface that allows variousmanagement agents 131 in other storage operation cells to communicatewith one another. For example, assume a certain network configurationincludes multiple storage operation cells hierarchically arranged orotherwise logically related in a WAN or LAN configuration. With thisarrangement, each storage operation cell may be connected to the otherthrough each respective interface agent 125. This allows each storageoperation cell to send and receive certain pertinent information fromother storage operation cells, including status information, routinginformation, information regarding capacity and utilization, etc. Thesecommunications paths may also be used to convey information andinstructions regarding storage operations.

For example, a management agent 131 in a first storage operation cellmay communicate with a management agent 131 in a second storageoperation cell regarding the status of storage operations in the secondstorage operation cell. Another illustrative example includes the casewhere a management agent 131 in a first storage operation cellcommunicates with a management agent 131 in a second storage operationcell to control storage manager 105 (and other components) of the secondstorage operation cell via management agent 131 contained in storagemanager 105.

Another illustrative example is the case where management agent 131 in afirst storage operation cell communicates directly with and controls thecomponents in a second storage operation cell and bypasses the storagemanager 105 in the second storage operation cell. If desired, storageoperation cells can also be organized hierarchically such thathierarchically superior cells control or pass information tohierarchically subordinate cells or vice versa.

Storage manager 105 may also maintain an index, a database, or otherdata structure 111. The data stored in database 111 may be used toindicate logical associations between components of the system, userpreferences, management tasks, media containerization and data storageinformation or other useful data. For example, the storage manager 105may use data from database 111 to track logical associations betweensecondary storage computing device 165 and storage devices 115 (ormovement of data as containerized from primary to secondary storage).

Generally speaking, the secondary storage computing device 165, whichmay also be referred to as a media agent, may be implemented as asoftware module that conveys data, as directed by storage manager 105,between a client 130 and one or more storage devices 115 such as a tapelibrary, a magnetic media storage device, an optical media storagedevice, or any other suitable storage device. In one embodiment,secondary storage computing device 165 may be communicatively coupled toand control a storage device 115. A secondary storage computing device165 may be considered to be associated with a particular storage device115 if that secondary storage computing device 165 is capable of routingand storing data to that particular storage device 115.

In operation, a secondary storage computing device 165 associated with aparticular storage device 115 may instruct the storage device to use arobotic arm or other retrieval means to load or eject a certain storagemedia, and to subsequently archive, migrate, or restore data to or fromthat media. Secondary storage computing device 165 may communicate witha storage device 115 via a suitable communications path such as a SCSIor Fibre Channel communications link. In some embodiments, the storagedevice 115 may be communicatively coupled to the storage manager 105 viaa SAN.

Each secondary storage computing device 165 may maintain an index, adatabase, or other data structure 161 that may store index datagenerated during storage operations for secondary storage (SS) asdescribed herein, including creating a metabase (MB). For example,performing storage operations on Microsoft Exchange data may generateindex data. Such index data provides a secondary storage computingdevice 165 or other external device with a fast and efficient mechanismfor locating data stored or backed up. Thus, a secondary storagecomputing device index 161, or a database 111 of a storage manager 105,may store data associating a client 130 with a particular secondarystorage computing device 165 or storage device 115, for example, asspecified in a storage policy, while a database or other data structurein secondary storage computing device 165 may indicate wherespecifically the data of the client 130 is stored in storage device 115,what specific files were stored, and other information associated withstorage of the data of the client 130. In some embodiments, such indexdata may be stored along with the data backed up in a storage device115, with an additional copy of the index data written to index cache ina secondary storage device. Thus the data is readily available for usein storage operations and other activities without having to be firstretrieved from the storage device 115.

Generally speaking, information stored in cache is typically recentinformation that reflects certain particulars about operations that haverecently occurred. After a certain period of time, this information issent to secondary storage and tracked. This information may need to beretrieved and uploaded back into a cache or other memory in a secondarycomputing device before data can be retrieved from storage device 115.In some embodiments, the cached information may include informationregarding format or containerization of archives or other files storedon storage device 115.

One or more of the secondary storage computing devices 165 may alsomaintain one or more single instance databases 123. More details as tosingle instancing may be found in one or more of the followingcommonly-assigned U.S. patent applications: 1) U.S. patent applicationSer. No. 11/269,512 (entitled SYSTEM AND METHOD TO SUPPORT SINGLEINSTANCE STORAGE OPERATIONS, Attorney Docket No. 60692-8023.US00); 2)U.S. patent application Ser. No. 12/145,347 (entitled APPLICATION-AWAREAND REMOTE SINGLE INSTANCE DATA MANAGEMENT, Attorney Docket No.60692-8056.US00); or 3) U.S. patent application Ser. No. 12/145,342(entitled APPLICATION-AWARE AND REMOTE SINGLE INSTANCE DATA MANAGEMENT,Attorney Docket No. 60692-8057.US00), 4) U.S. patent application Ser.No. 11/963,623 (entitled SYSTEM AND METHOD FOR STORING REDUNDANTINFORMATION, Attorney Docket No. 60692-8036.US02); 5) U.S. patentapplication Ser. No. 11/950,376 (entitled SYSTEMS AND METHODS FORCREATING COPIES OF DATA SUCH AS ARCHIVE COPIES, Attorney Docket No.60692-8037.US01); or 6) the previously referenced U.S. patentapplication Ser. No. 12/565,576, each of which is incorporated byreference herein in its entirety.

In some examples, the secondary storage computing devices 165 maintainone or more variable instance databases. Variable instancing generallyrefers to storing in secondary storage one or more instances, but fewerthan the total number of instances, of each data block (or data object)in a set of data (e.g., primary data). More details as to variableinstancing may be found in the commonly-assigned U.S. Pat. App. No.61/164,803 (entitled STORING A VARIABLE NUMBER OF INSTANCES OF DATAOBJECTS, Attorney Docket No. 60692-8068.US00).

In some embodiments, certain components may reside and execute on thesame computer. For example, in some embodiments, a client 130 such as adata agent 195, or a storage manager 105, coordinates and directs localarchiving, migration, and retrieval application functions as furtherdescribed in the previously-referenced U.S. patent application Ser. No.09/610,738. This client 130 can function independently or together withother similar clients 130.

As shown in FIG. 1, each secondary storage computing device 165 has itsown associated metabase 161. Each client 130 may also have its ownassociated metabase 170. However in some embodiments, each “tier” ofstorage, such as primary storage, secondary storage, tertiary storage,etc., may have multiple metabases or a centralized metabase, asdescribed herein. For example, rather than a separate metabase or indexassociated with each client 130 in FIG. 1, the metabases on this storagetier may be centralized. Similarly, second and other tiers of storagemay have either centralized or distributed metabases. Moreover, mixedarchitecture systems may be used if desired, that may include a firsttier centralized metabase system coupled to a second tier storage systemhaving distributed metabases and vice versa, etc.

Moreover, in operation, a storage manager 105 or other management modulemay keep track of certain information that allows the storage manager105 to select, designate, or otherwise identify metabases to be searchedin response to certain queries as further described herein. Movement ofdata between primary and secondary storage may also involve movement ofassociated metadata and other tracking information as further describedherein.

In some examples, primary data may be organized into one or moresub-clients. A sub-client is a portion of the data of one or moreclients 130, and can contain either all of the data of the clients 130or a designated subset thereof. As depicted in FIG. 1, the data store162 includes two sub-clients. For example, an administrator (or otheruser with the appropriate permissions; the term administrator is usedherein for brevity) may find it preferable to separate email data fromfinancial data using two different sub-clients having different storagepreferences, retention criteria, etc.

Components of a Block-Level Single Instancing System

FIG. 2 is a block diagram depicting in more detail certain componentsillustrated in FIG. 1. The data agent 195 of the client 130 includesvarious components, such as a data identification component 202, a blockidentification component 204, and an identifier generation component206. The data agent 195 also includes a compression component 210, anencryption component 212, and a data stream generation component 214.Various functions performed by these components are described herein.

In addition to the data agent 195, the client 130 includes data 240. Thedata 240 includes single instanceable data (SI data) 242 and non-singleinstanceable data (non-SI data) 244. SI data 242 includes data that iseligible for single instancing. Non-SI data 244 includes data that isnot eligible for single instancing. Non-SI data 244 may include metadatasuch as access control lists (ACLs), disk partition information, MasterFile Table (MFT) or File Allocation Table (FAT) information, and/orother metadata. Non-SI data 244 may also include other data that isdetermined not to be single instanceable. SI data 242 may include data240 of the client 130 other than non-SI data 244 (e.g., system files,application files, user files, etc.).

The secondary storage computing device 165 includes a data streamreception component 220 and an identifier comparison component 222.Various functions performed by these components are also described indetail herein. The secondary storage computing device 165 also includesa memory 230, which includes multiple buffers 232. The secondary storagecomputing device 165 may also include other components, such as adecompression component and/or a decryption component. The singleinstance database 123 includes data structures 250 that are used tostore data, such as metadata about SI data 242. The storage device 115also includes data structures 260 that are used to store data, such asSI data 242 and non-SI data 244. In some examples, the secondary storagecomputing device 165 includes the components that the client 130includes, and performs the functions that the client 130 performs.

Processes for Performing Storage Operations

FIGS. 3 and 4 are flow diagrams illustrating certain aspects ofprocesses 300 and 400, respectively, for performing a storage operationsuch as a copy operation. A storage operation (alternatively referred toas a job) is typically performed on files stored on file systems of oneor more clients 130. One or more of the entities illustrated in thefigures (e.g., FIGS. 1 and/or 2) may perform different aspects of theprocesses 300 and 400. In some examples, a storage manager 105instigates the process 300 by sending an indication specifying thestorage operation to the data agent 195. The data agent 195 accesses thedata of the client 130 (e.g., accesses files stored on the filesystem ofthe client 130). The data agent 195 sends the data to the secondarystorage computing device 165, which then stores the data on one or morestorage devices 115. In some examples, less than all of these entitiesmay be involved in performing the storage operation. The process 300 isdescribed as being performed by the data agent 195 and the process 400is described as being performed by the secondary storage computingdevice 165. However, those of skill in the art will understand thataspects of the processes 300 and 400 may be performed by any one or moreof the entities described herein (e.g., the data agent 195, the storagemanager 105, the secondary storage computing device 165, etc.).

The process 300 begins at step 305 where the data agent 195 receives anindication to copy data of the client 130. The storage manager 105 maysend the indication to the data agent 195 (e.g., according to a storagepolicy), an administrator may manually start the process 300, and/or theprocess 300 may be automatically started according to a schedule policy.

At step 310 the data agent 195 accesses the data 240 of the client 130.The data agent 195 (e.g., the data identification component 202)determines which portions of the data 240 are SI data 242 and whichportions are non-SI data 244. For example, the data agent 195 maydetermine that metadata (e.g., MFT, FAT, volume information, transactionlogs, etc.) on the file system of the client 130 is non-SI data 244, andthat data other than metadata is SI data 242 (e.g., system files, userfiles, etc.). At step 315 the data agent 195 (e.g., the data streamgeneration component 214) forms a data stream of multiple pairs ofstream header and stream payload from the SI data 242 and the non-SIdata 244. (An example data stream is illustrated in FIG. 5A and isdescribed in detail below.) A data stream, therefore, comprises multiplepairs of stream header and stream payload. However, those of skill inthe art will understand that data streams may contain data organized inother fashions. For the SI data 242, the data agent 195 may set a flagin the stream header to indicate that the corresponding stream payloadcontains single instanceable data.

At step 320, the data agent 195 (e.g., the identifier generationcomponent 206) aligns the stream header and stream payload into one ormore fixed size blocks of data. (An example data stream with streamheader and stream payload aligned into multiple blocks is illustrated inFIG. 5B and is described in detail below.) A block of data(alternatively called a data block) is a sequence of bits or byteshaving a nominal length (a data block size). The file system of theclient 130 may track its data 240 in blocks (alternatively calledclusters) in sizes of 512 bytes, 4 KB, 16 KB, or other sizes. (Putanother way, a block may be a subset of one or more data objects.) Afile on the file system of the client 130 typically spans one or moreblocks (e.g., a file of size 10 KB may span 3 blocks of size 4 KB). Thedata agent 195 typically aligns data blocks such that they have the samesize, which may be 32 KB, 64 KB, 128 KB, 256 KB, 512 KB, or other sizes.Accordingly, the term data block, as used herein, may comprise one ormore blocks as tracked by the file system of the clients 130. Forexample, if the file system of a client 130 tracks its data 240 inblocks of size 4 KB and if the data agent 195 aligns the client's 130data 240 into data blocks of size 128 KB, then these 128 KB data blockscomprise 32 blocks of data 240 as tracked by the file system of theclient 130.

At step 325 the data agent 195 determines whether a data block is singleinstanceable. The data agent 195 does so by analyzing the portion of theone or more corresponding stream headers that indicates whether the datablock is single instanceable. For example, the stream headers maycontain a flag or bit that indicates whether the successive streampayload contain single instanceable data. (For example, see FIG. 5A,illustrating stream headers containing such flags.) If the data block issingle instanceable, the process 300 continues at step 330, where thedata agent 195 (e.g., the identifier generation component 206) generatesan identifier for the data block.

Examples of identifiers include a hash value, message digest, checksum,digital fingerprint, digital signature or other sequence of bytes thatsubstantially uniquely identifies the data block in the data storagesystem. For example, identifiers could be generated using Message DigestAlgorithm 5 (MD5) or Secure Hash Algorithm SHA 512. In some instances,the phrase “substantially unique” is used to modify the term“identifier” because algorithms used to produce hash values may resultin collisions, where two different data objects, when hashed, result inthe same hash value. However, depending upon the algorithm orcryptographic hash function used, collisions should be suitably rare andthus the identifier generated for a block should be unique throughoutthe data storage system. The term “probabilistically unique identifier”may also be used. In this case, the phrase “probabilistically unique” isused to indicate that collisions should be low-probability occurrences,and, therefore, the identifier should be unique throughout the datastorage system.

At step 335 the data agent 195 (e.g., the identifier generationcomponent 206) inserts the generated identifier into the data stream.The generated identifier may be comprised in an identifier header andidentifier data pair that immediately follows the data block for whichit is generated. (See FIG. 5B and the accompanying description foradditional details of the identifier header and identifier data pair.)At step 340 the data agent 195 determines whether there are more datablocks. If so, the process 300 returns to step 325. If not, the process300 continues at step 345, where the data agent 195 transfers the datastream to the secondary storage computing device 165. The process 300then ends. In some examples, the data agent 195 may perform additionaloperations upon the stream header and/or stream payload, such asencrypting the stream payload (e.g., using the encryption component 212)and/or compressing the stream payload (e.g., using the compressioncomponent 210).

FIG. 4 is a flow diagram illustrating certain aspects of the process 400that the secondary storage computing device 165 performs upon receivingthe data stream from the data agent 195. At step 405 the secondarystorage computing device 165 receives the data stream from the dataagent 195. At step 410, the secondary storage computing device 165stores the stream header and stream payload corresponding to a datablock in a buffer 232 of the memory 230. The secondary storage computingdevice 165 can store the entire stream header and stream payload pairscorresponding to a single block in a single buffer, because the buffersize (e.g., approximately 640 KB) is greater than the size of the streamheader and stream payload pairs (e.g., up to approximately 512 KB). Thebuffer size is typically no greater than 10 times the size of the streamheader and stream payload pairs. In some examples, the memory 230includes 30 buffers 232, thus allowing the secondary storage computingdevice 165 to simultaneously store up to 30 different data blocks infast-access memory. The ability to store multiple data blocks in memoryenables the secondary storage computing device 165 to avoid writing themultiple data blocks to disk, which can be a lengthy operation.

At step 415 the secondary storage computing device 165 determineswhether the data block is single instanceable. The secondary storagecomputing device 165 may do so, for example, by analyzing the metadatain the stream header that indicates whether the data block is singleinstanceable (e.g., a flag or bit that indicates whether the data blockis single instanceable).

If the data block is single instanceable, the process 400 continues atstep 425, where the secondary storage computing device (e.g., theidentifier comparison component 222) obtains the identifiercorresponding to the data block (e.g., from the identifier data of thedata stream) and looks up the identifier. The secondary storagecomputing device 165 looks up the identifier in the primary table in thesingle instance database 123. (Example data structures used by thesingle instance database 123 are illustrated in FIGS. 6A and 6B anddescribed with reference to these figures).

At step 430, if the secondary storage computing device 165 finds theidentifier of the data block in the primary table, this indicates thatan instance of the data block is already stored on the storage device115, and that the block of data should not be stored. Accordingly, thesecondary storage computing device 165 can avoid storing anotherinstance of the data block and can instead store a link (alternativelycalled a pointer) to the location(s) of the already stored instance. Atstep 445 the secondary storage computing device 165 adds a link to thelocation(s) of the already stored instance of the data block to ametadata file. The link refers or points to the already stored instanceof the data block. For example, the secondary storage computing device165 may add as the link to the metadata file the record of the alreadystored instance of the data block in the primary table. At step 450 thesecondary storage computing device 165 adds an entry to the secondarytable in the single instance database. The entry includes the locationof the link in the metadata file. The secondary storage computing device165 also increments a reference count corresponding to the data block inthe primary table. The reference count indicates the number of links tothe already stored instance of the data block. At step 455 the secondarystorage computing device 165 discards the stream header and streampayload corresponding to the data block from the buffer 232 of thememory 230. Additionally or alternatively, the secondary storagecomputing device 165 may indicate that the buffer is available forstoring another pair of stream header and stream payload.

If the secondary storage computing device 165 does not find theidentifier of the block in the primary table (step 430), this indicatesthat no instances of the data block are already stored on the storagedevice 115, and that the block of data should be stored. Accordingly, atstep 435 the secondary storage computing device 165 stores the datablock in a container file on the storage device 115. (See FIG. 7 and theaccompanying description for additional details of container files.) Atstep 440 the secondary storage computing device 165 adds an entry to theprimary table in the single instance database. The entry includes thelocation of the data block in the container file.

If the data block is not single instanceable (step 415), the process 400continues at step 420, where the secondary storage computing device 165stores the block in a metadata file. (See FIG. 7 and the accompanyingdescription for additional details of metadata files.) The threebranches of the process 400 converge at step 460, where the secondarystorage computing device 165 determines whether there are more datablocks. If so, the process 400 returns to step 415. If not the process400 concludes.

In some examples, the secondary storage computing device 165 may performadditional operations during the process 400, such as decrypting thestream payload (e.g., using a decryption component) and/or decompressingthe stream payload (e.g., using a decompression component). Thesecondary storage computing device 165 may also store in the index 161,for the data blocks, information mapping an archive file and offset tothe physical location of the data blocks. An archive file is a logicalentity that is created during a storage operation and that correspondsto physical locations of data blocks on the storage device 115. Thestorage manager 105 may map archive files to physical locations and keepsuch information in index 111.

In some examples, a variable number of instances of data blocks (e.g.,more than one instance and up to N−1 instances, where N is the number ofinstances of the data block in primary data) is stored on the storagedevices 115. In such examples, the secondary storage computing devices165 may use techniques described in the previously referenced U.S. Pat.App. No. 61/164,803 to ensure that a sufficient number of instances ofthe blocks of data are stored on the storage devices 115. Storingmultiple instances (up to N−1) of N data blocks provides for less riskof data loss than single instance storage techniques, and generallynearly as less risk of data loss as conventional data protectiontechniques (which store N instances of N data blocks). Storing multipleinstances (up to N−1) of N data blocks also provides for more efficientuse of available storage space than conventional data protectiontechniques, and almost as efficient use as single instance storagetechniques. Accordingly, the storing of a variable number of instancesof data blocks enables an administrator to tailor data protection tostrike an appropriate balance between 1) minimizing the risk of dataloss, and 2) making efficient use of available data storage space, inaccordance with the administrator's requirements.

Suitable Data Structures

FIGS. 5A and 5B are diagrams of example data streams 500 and 550,respectively, that may be employed by aspects of the invention.Referring to FIG. 5A, the data agent 195 forms the data stream 500 fromthe data 240 of the client 130. The data stream 500 is composed ofmultiple pairs of stream header 502 and stream payload 504. A streampayload 504 includes SI data 242 and/or non-SI data 244. A stream header502 includes metadata about the stream payload 504. This metadata mayinclude, for example, a length of the stream payload 504, an indicationof whether the stream payload 504 is encrypted, an indication of whetherthe stream payload 504 is compressed, an archive file identifier (ID),an indication of whether the stream payload 504 is single instanceable,and an indication of whether the stream payload 504 is a start of ablock of data.

Referring to FIG. 5B, the data stream 550 has the stream header 502 andstream payload 504 aligned into multiple data blocks. In this example,the data blocks are of size 64 KB. The first two stream header 502 andstream payload 504 pairs comprise a first data block of size 64 KB. Thefirst stream header 502 indicates that the length of the succeedingstream payload 504 is 63 KB and that it is the start of a data block.(The stream header 502 may also include the metadata discussed withreference to the stream headers 502 illustrated in FIG. 3A.) The nextstream header 502 indicates that the succeeding stream payload 504 has alength of 1 KB and that it is not the start of a new data block.Immediately following stream payload 504 are an identifier header 506and identifier data 508 pair. The identifier header 506 includes anindication that the succeeding identifier data 508 includes theidentifier for the immediately previous data block. The identifier data508 includes the identifier that the data agent (e.g., the identifiergeneration component 206) generated for the data block. The data stream550 also includes other stream header 502 and stream payload 504 pairs,which may be for SI data 242 and/or for non-SI data 244.

FIGS. 6A and 6B are diagrams illustrating the data structures 250 thatmay be used by the single instance database 123. The data structures 250do not form part of a native file system of a storage device storing thesingle instance database 123. Alternatively, the data structures 250 arenot provided by any native file system for storage devices at least asof the time of the filing of the provisional patent application to whichthis application claims priority. The data structures 250 include aprimary table 600 and a secondary table 650.

Referring to FIG. 6A, the primary table 600 includes an identifiercolumn 602 in which a data block identifier is stored, a location column604 in which a location of the data block in a container file is stored,an offset column 606 indicating the offset within the container filecorresponding to the location of the data block, and a reference countcolumn 608, which contains a reference count of the number of links thatrefer to the data block. For example, row 620 includes information abouta data block for which the identifier is “0xA1B3FG.” This data block islocated in the container file that is indicated in the location column606, at an offset of 10 within the container file. As indicated in thereference count column 608, this data block is referred to twice,meaning that there are two links that refer to the data block. Asanother example, row 624 includes information about a data block forwhich the identifier is “0xC13804.” The location of this data block isindicated in the location column 604 at an offset of 38 within thecontainer file, and it is referred to one other time, by one link.

Referring to FIG. 6B, the secondary table 650 includes information aboutlinks that refer to data blocks. The secondary table 650 includes anidentifier column 652, a referring location column 654, and an offsetcolumn 656. For example, row 660 includes information about a referenceto the data block having the identifier of “0xA1 B3FG” (row 620 in theprimary table 600). The location of the link is indicated in column 654,at an offset of five within the indicated metadata file. As anotherexample, row 662 includes information about another reference to thedata block having the identifier of “0xA1B3FG.” This link is located atthe location indicated in column 654, at an offset of 15 within theindicated metadata file. As another example, row 664 includesinformation about a reference to the block for which the identifier is“0xC13804” (row 624 in the primary table 600). The location of the linkis indicated in column 654, at an offset of 19 within the indicatedmetadata file.

FIG. 7 is a diagram illustrating the data structures 260 that may beused to store blocks of SI data and non-SI data on the storage device115. The data structures 260 do not form part of a native file system ofthe storage device 115. Alternatively, the data structures 260 are notprovided by any native file systems for storage devices at least as ofthe time of the filing of the provisional patent application to whichthis application claims priority.

The data structures 260 include one or more volume folders 702, one ormore chunk folders 704/705 within a volume folder 702, and multiplefiles within a chunk folder 704. Each chunk folder 704/705 includes ametadata file 706/707, a metadata index file 708/709, one or morecontainer files 710/711/713, and a container index file 712/714. Themetadata file 706/707 stores non-SI data blocks as well as links to SIdata blocks stored in container files. The metadata index file 708/709stores an index to the data in the metadata file 706/707. The containerfiles 710/711/713 store SI data blocks. The container index file 712/714stores an index to the container files 710/711/713. Among other things,the container index file 712/714 stores an indication of whether acorresponding block in a container file 710/711/713 is referred to by alink in a metadata file 706/707. For example, data block B2 in thecontainer file 710 is referred to by a link in the metadata file 707 inthe chunk folder 705. Accordingly, the corresponding index entry in thecontainer index file 712 indicates that the data block B2 in thecontainer file 710 is referred to. As another example, data block B1 inthe container file 711 is referred to by a link in the metadata file707, and so the corresponding index entry in the container index file712 indicates that this data block is referred to.

As an example, the data structures 260 illustrated in FIG. 7 may havebeen created as a result of two storage operations involving two clients130. For example, a first storage operation on a first client 130 couldresult in the creation of the first chunk folder 704, and a secondstorage operation on a second client 130 could result in the creation ofthe second chunk folder 705. The container files 710/711 in the firstchunk folder 704 would contain the blocks of SI data 242 of the firstclient 130. If the two clients 130 have substantially similar data 240,the second storage operation on the data 240 of the second client 130would result in the secondary storage computing device 165 storingprimarily links to the data blocks of the first client 130 that arealready stored in the container files 710/711. Accordingly, while afirst storage operation may result in storing nearly all of the datasubject to the storage operation, subsequent storage operationsinvolving similar data may result in substantial data storage spacesavings, because links to already stored data blocks can be storedinstead of additional instances of data blocks.

If the operating system of the secondary storage computing device 165supports sparse files, then when the secondary storage computing device165 creates container files 710/711/713, it can create them as sparsefiles. As previously described, a sparse file is type of file that mayinclude empty space (e.g., a sparse file may have real data within it,such as at the beginning of the file and/or at the end of the file, butmay also have empty space in it that is not storing actual data, such asa contiguous range of bytes all having a value of zero). Having thecontainer files 710/711/713 be sparse files allows the secondary storagecomputing device 165 to free up space in the container files 710/711/713when blocks of data in the container files 710/711/713 no longer need tobe stored on the storage devices 115. In some examples, the secondarystorage computing device 165 creates a new container file 710/711/713when a container file 710/711/713 either includes 100 blocks of data orwhen the size of the container file 710 exceeds 50 Mb. In otherexamples, the secondary storage computing device 165 creates a newcontainer file 710/711/713 when a container file 710/711/713 satisfiesother criteria (e.g., it contains from approximately 100 toapproximately 1000 blocks or when its size exceeds approximately 50 Mbto 1 Gb). Those of skill in the art will understand that the secondarystorage computing device 165 can create a new container file 710/711/713when other criteria are met.

In some cases, a file on which a storage operation is performed maycomprise a large number of data blocks. For example, a 100 Mb file maybe comprised in 400 data blocks of size 256 KB. If such a file is to bestored, its data blocks may span more than one container file, or evenmore than one chunk folder. As another example, a database file of 20 Gbmay comprise over 40,000 data blocks of size 512 KB. If such a databasefile is to be stored, its data blocks will likely span multiplecontainer files, multiple chunk folders, and potentially multiple volumefolders. As described in detail herein, restoring such files may thusrequiring accessing multiple container files, chunk folders, and/orvolume folders to obtain the requisite data blocks.

One advantage of the data structures 260 illustrated in FIG. 7 and/or ofthe techniques described herein is that they significantly reduce thenumber of files stored on a file system of the storage device 115. Thisis at least partly due to the storage of data blocks within thecontainer files 710/711/713. Even if numerous storage operations usingthese data structures 260 are performed, this will result in far fewerfiles on the storage device 115 than storage operations where each datablock is stored as a separate file. Therefore, the file system of thestorage device 115 may not necessarily have to contend with storingexcessively large numbers of files, such as millions of files or more.Accordingly, the systems and methods described herein enable very largenumbers of blocks of data to be stored without regard to limitations ofthe file system of the storage device 115.

Another advantage is that the data storage system enables a reduction inthe amount of blocks of data stored on the storage devices 115, whilestill maintaining at least one instance of each block of primary data.In examples where the data storage system stores a variable number ofinstances of blocks of primary data, blocks of primary data can bedistributed across two or more storage devices 115, thereby adding afurther aspect of redundancy.

Another advantage is that the metadata files 706/707, the metadata indexfiles 708/709, the container files 710/711/713, and/or the containerindex files 712/714 could be used to replicate the data stored in thesingle instance database 123 or reconstruct the single instance database123 if the data of the single instance database 123 is ever lost and/orcorrupted.

The storage of data blocks in the container files may create additionalcomplexities when it comes time to prune data blocks (pruning datablocks may be alternatively referred to as deleting or removing datablocks) that the data storage system no longer need retain. This isbecause the data blocks are not stored as files on the file system onthe storage device 115 and thus cannot be directly referenced by thefile system using the file system's data structures (the data structuresthat are built into or provided with the file system). As described indetail with reference to FIG. 9, the secondary storage computing device165 uses the container index files 712/714 to keep track of which blocksof data are referenced and thus which blocks are not prunable(deletable).

In some examples, the use of the container index files 712/714, themetadata index files 708/709, and/or the primary and secondary tables600/650 to track data is analogous to a driver, agent or an additionalfile system that is layered on top of the existing file system of thestorage device 115. This driver/agent/additional file system allows thedata storage system to efficiently keep track of very large numbers ofblocks of data, without regard to any limitations of the file systems ofthe storage devices 115. Accordingly, the data storage system can storevery large numbers of blocks of data.

Accordingly, the data structures 260 illustrated in FIG. 7 and thetechniques described herein enable the performance of multiple storageoperations cumulatively involving very large amounts of data, whilestill allowing for recovery of space on the storage device 115 whenstorage of certain data blocks is no longer required. For example, thedata of numerous clients 130 can be protected without having to storeredundant copies or instances of data blocks. Space on the storagedevice 115 can also be recovered when it is no longer necessary to storecertain data blocks. Accordingly, storage operations involving verylarge amounts of data are enabled and optimized by the techniquesdescribed herein.

Process for Restoring Data

FIG. 8 is a flow diagram of a process 800 for restoring one or moreblocks of data. The process 800 is described as being performed by thesecondary storage computing device 165, although those of skill in theart will understand that aspects of the process 800 may be performed byany of the entities described herein. The process 800 begins at step 805where the secondary storage computing device 165 receives a selection ofdata to restore (e.g., one or more files). For example, an administratormay utilize an integrated management console that provides an interfacefor allowing the administrator to specify one or more data blocks to berestored (e.g., by allowing the administrator to specify one or morefiles to be restored). As another example, a client 130 may request thata data block that had been previously copied from the client 130 berestored to the client 130. At step 810 the secondary storage computingdevice 165 determines an archive file and offset within the archive filecorresponding to the data to be restored. The secondary storagecomputing device 165 may analyze the index 111 of the storage manager105 to determine the archive file and offset.

At step 815 the secondary storage computing device 165 determines volumefolders and chunk folders corresponding to the archive file and offset.The secondary storage computing device 165 may do so by analyzing theindex 161 to determine the volume folders and chunk folders. Thedetermined volume folders and chunk folders contain the requested data.At step 820 the secondary storage computing device 165 accesses an indexfile within the determined volume folders and chunk folders thatcorresponds to the data to be restored. This may be the metadata indexfile 708/709 when the requested data is non-SI data 244 or the containerindex file 712/714 when the requested data is SI data 242. At step 825the secondary storage computing device 165 determines, from the indexfile, the offset within the metadata file 706/707 or the offset withinthe container file 710/711/13 corresponding to the requested data. Atstep 830 the secondary storage computing device 165 accesses themetadata file 706/707 or the container file 710/711/13 and seeks to thedetermined offset. At step 835 the secondary storage computing device165 retrieves the data from the metadata file 706/707 or the containerfile 710/711/13. At step 840 the secondary storage computing devicerestores the data to a selected location (e.g., to a client 130 and/orto another location). The process 800 then concludes.

As previously noted, restoring a file may necessitate accessing multiplecontainer files, chunk folders, and/or volume folders to obtain the datablocks that comprise the file. The secondary storage computing device165 may thus have to obtain a first data block from a first containerfile and a second data block from a second container file. As anotherexample, the secondary storage computing device 165 may thus have toobtain a first data block from a first container file within a firstfolder and a second data block from a second container file within asecond folder. To do so, the secondary storage computing device 165 mayhave to access multiple index files or other data structures to locatethe requisite blocks of data. Those of skill in the art will understandthat various techniques may be used to restore data such as files andother data.

Process for Pruning Data

FIG. 9 is a flow diagram of a process 900 for pruning data. The process900 is described as being performed by the secondary storage computingdevice 165, although those of skill in the art will understand thataspects of the process 900 may be performed by any of the entitiesdescribed herein. The process 900 begins when the secondary storagecomputing device 165 receives instructions to prune data correspondingto a storage operation (job). Additionally or alternatively, one or morefiles can be selected to be pruned, and/or one or more data blocks canbe selected to be pruned. This selection of a job or other data to bedeleted can be made manually, such as by an administrator, orautomatically, such as by the job, files, and/or data blocks aging outby a retention policy.

As previously noted, the data structures 260 illustrated in FIG. 7 mayhave been created as a result of two jobs involving two clients 130. Forexample, a first job on a first client 130 could result in the creationof the first chunk folder 704, and a second job on a second client 130could result in the creation of the second chunk folder 705. The process900 is described using this example. More specifically, the process 900is described below as pruning the data created as a result of the firstjob. Of course, a similar process may be used to delete other jobs, oreven smaller increments of data or data objects, such as individualfiles or blocks.

At step 907 the secondary storage computing device 165 determines thefile, e.g., archive file, and the volume folders 702 and chunk folder704 corresponding to the job to be pruned. The secondary storagecomputing device 165 may do so, for example, by analyzing the index 111and/or the index 161 to determine this information. At step 910 thesecondary storage computing device 165 deletes the metadata file 706 andthe metadata index file 708 in the chunk folder 704. The secondarystorage computing device 165 can delete the metadata file 706 and themetadata index file 708 in this example because these files includenon-SI data 244, which is not referenced by any other data.

At step 915 the secondary storage computing device 165 accesses thecontainer file 710 and the container index file 712 in the chunk folder704. The secondary storage computing device 165 begins iterating throughthe data blocks in the container files 710. At step 920, beginning witha first block in the container file 710, the secondary storage computingdevice 165 accesses the primary table 600 in the single instancedatabase 123. The secondary storage computing device 165 determines fromthe primary table 600 whether the reference count of a data block in thecontainer file 710 is equal to zero. If so, this indicates that thereare no references to the data block. The process 900 then continues atstep 925, where the secondary storage computing device 165 sets theentry in the container index file 712 corresponding to the data blockequal to zero, thus indicating that there are no references to the datablock, and therefore prunable.

If the reference count of a data block is not equal to zero, then thedata block is not prunable, and the process 900 continues at step 930.At this step, the secondary storage computing device 165 determineswhether there are more data blocks in the container file 710. If so, theprocess 900 returns to step 920, where it accesses the next data block.If there are no more data blocks in the container file 710, the process900 continues at step 932, where the secondary storage computing device165 determines whether all the entries in the container index file 712corresponding to the container file 710 are equal to zero. Asillustrated in FIG. 7, the second index entry in the container indexfile 712 is not equal to zero, thus indicating that the correspondingblock in container file 710 is referenced (by data in the chunk folder705, as earlier described). Accordingly, the container file 710 cannotbe deleted.

However, if the container file 710 did not contain any referenced datablocks, then at step 933, the secondary storage computing device 165would delete the container file 710. The process would then continue atstep 935, where the secondary storage computing device 165 determineswhether there are more container files. According to the example asillustrated in FIG. 7, there is an additional container file 711. Theprocess 900 then returns to step 915, where it performs the same steps920-933 for container file 711. As a result of performing these steps,the secondary storage computing device 165 would also determine that thecontainer file 711 cannot be deleted, because it contains a data blockthat is referenced (by data in the chunk folder 705, as earlierdescribed).

After processing container files 710/711, the process 900 continues atstep 940, where the secondary storage computing device 165 determineswhether to free up storage space in the container files 710/711. Thesecondary storage computing device 165 may do so using varioustechniques. For example, if the operating system of the secondarystorage computing device 165 supports sparse files, then the secondarystorage computing device 165 may free up space by zeroing out the bytesin the container files corresponding to the space to be freed up. For acertain number of contiguous blocks (e.g., a threshold number ofcontiguous blocks, such as three contiguous blocks) for which thecorresponding entries in the container index file 712 indicate that theblocks are not being referred to, then the secondary storage computingdevice 165 may mark these portions of the container files 710/711 asavailable for storage by the operating system or the file system. Thesecondary storage computing device 165 may do so by calling an API ofthe operating system to mark the unreferenced portions of the containerfiles 710/711 as available for storage.

The secondary storage computing device 165 may use certain optimizationsto manage the number of times portions of the container file arespecified or marked as available for storage, such as only zeroing outbytes in container files when a threshold number of unreferencedcontiguous blocks is reached (e.g., three or more unreferencedcontiguous blocks). These optimizations may result in less overhead forthe operating system because it reduces the number of contiguous rangesof zero-value bytes in the container files 710/711 that the operatingsystem must keep track of (e.g., it reduces the amount of metadata aboutportions of the container files 710/711 that are available for storage).

If the operating system of the secondary storage computing device 165does not support sparse files, then the secondary storage computingdevice 165 may free up space by truncating either the beginning or theend of the container files 710/711 (removing or deleting data at thebeginning or end of the container files 710/711). The secondary storagecomputing device 165 may do so by calling an API of the operatingsystem, or by operating directly on the container files 710/711. Forexample, if a certain number of the last blocks of the container fileare not being referred to, the secondary storage computing device 165may truncate these portions of the container files 710/711. Othertechniques may be used to free up space in the container files 710/711for storage of other data. At step 945 the secondary storage computingdevice 165 frees up space in the container files 710/711. The process900 then concludes.

As a result of the process 900, the chunk folder 704 would contain onlythe container files 710/711 and the container index file 712. At a latertime, when the chunk folder 705 is pruned (that is, when the job thatcreated this chunk folder is selected to be pruned), then the containerfiles 710/711 in the chunk folder 704 can be deleted, because they nolonger contain data blocks that is referenced by other data. Therefore,pruning data corresponding to a job may also result in pruning datacorresponding to an earlier job, because the data corresponding to theearlier job is no longer referenced by the later job.

Although the process 900 is described with reference to the pruning ofdata corresponding to jobs (one or more storage operations), other datacan also be pruned. For example, an administrator may wish to delete SIdata 242 but retain non-SI data 244. In such case, the administrator mayinstruct the secondary storage computing device 165 to delete thecontainer files 710/711/713 but retain the metadata files 706/707 andmetadata index files 708/709. As another example, an administrator orstorage policy may delete one or more specific files. In such case, thesecondary storage computing device 165 deletes the data blocks in thecontainer files 710/711/713 corresponding to the specific files butretains other data blocks. The process 900 may include fewer or moresteps than those described herein to accommodate these other pruningexamples. Those of skill in the art will understand that data can bepruned in various fashions and therefore, that the process 900 is notlimited to the steps described herein.

One advantage of the process 900 and the techniques described herein isthat they enable the deletion of data on the storage devices 115 that nolonger needs to be stored while still retaining data that needs to bestored, and doing so in a space-efficient manner. Space previouslyallocated for data blocks that no longer need to be stored can bereclaimed by the data storage system, and used to store other data.Accordingly, the techniques described herein provide for efficient useof available storage space (available on physical media).

CONCLUSION

From the foregoing, it will be appreciated that specific examples ofdata storage systems have been described herein for purposes ofillustration, but that various modifications may be made withoutdeviating from the spirit and scope of the invention. For example,although copy operations may have been described, the system may be usedto perform many types of storage operations (e.g., backup operations,restore operations, archival operations, copy operations, ContinuousData Replication (CDR) operations, recovery operations, migrationoperations, HSM operations, etc.). As another example, althoughblock-level single instancing has been described, the systems andmethods detailed herein may be used to single instance files. As anotherexample, the secondary storage computing device 165 may keep track ofwhich blocks of data in container files 710 are not referenced, insteadof keeping track of which blocks of data are referred to by links. Asanother example, non-SI data 244 may not be aligned into blocks of data.Accordingly, the invention is not limited except as by the appendedclaims.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as meaning “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof; the terms “a” or“an” should be read as meaning “at least one,” “one or more” or thelike; and adjectives such as “conventional,” “traditional,” “normal,”“standard,” “known” and terms of similar meaning should not be construedas limiting the item described to a given time period or to an itemavailable as of a given time, but instead should be read to encompassconventional, traditional, normal, or standard technologies that may beavailable or known now or at any time in the future. Likewise, wherethis document refers to technologies that would be apparent or known toone of ordinary skill in the art, such technologies encompass thoseapparent or known to the skilled artisan now or at any time in thefuture.

The presence of broadening words and phrases such as “one or more,” “atleast,” “but not limited to” or other like phrases in some instancesshall not be read to mean that the narrower case is intended or requiredin instances where such broadening phrases may be absent. The use of theterm “module” does not imply that the components or functionalitydescribed or claimed as part of the module are all configured in acommon package. Indeed, any or all of the various components of amodule, whether control logic or other components, can be combined in asingle package or separately maintained and can further be distributedin multiple groupings or packages or across multiple locations.

If a synchronization process or synchronization processes are describedherein, it is not intended to require that multiple synchronizationsoccur simultaneously or that multiple computing systems beingsynchronized each receive the same data. Although in some examples thedata can be broadcast to all participating computing systemssimultaneously (or close to simultaneously), in other examples the datacan be sent to different computing systems or groups of computingsystems at different times. Likewise, in some examples the same data, orthe same subset of the data can be sent to all computing systems.However, in other examples, subsets of the data can be tailored for agiven computing system or group of computing systems.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” The word “coupled,” as generally usedherein, refers to two or more elements that may be either directlyconnected, or connected by way of one or more intermediate elements.Additionally, the words “herein,” “above,” “below,” and words of similarimport, when used in this application, shall refer to this applicationas a whole and not to any particular portions of this application. Wherethe context permits, words in the above Detailed Description using thesingular or plural number may also include the plural or singular numberrespectively. The word “or” in reference to a list of two or more items,that word covers all of the following interpretations of the word: anyof the items in the list, all of the items in the list, and anycombination of the items in the list.

The above detailed description of embodiments of the invention is notintended to be exhaustive or to limit the invention to the precise formdisclosed above. While specific embodiments of, and examples for, theinvention are described above for illustrative purposes, variousequivalent modifications are possible within the scope of the invention,as those skilled in the relevant art will recognize. For example, whileprocesses or blocks are presented in a given order, alternativeembodiments may perform routines having steps, or employ systems havingblocks, in a different order, and some processes or blocks may bedeleted, moved, added, subdivided, combined, and/or modified. Each ofthese processes or blocks may be implemented in a variety of differentways. Also, while processes or blocks are at times shown as beingperformed in series, these processes or blocks may instead be performedin parallel, or may be performed at different times.

The teachings of the invention provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various embodiments described above can be combined toprovide further embodiments.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the invention can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further implementations of theinvention.

These and other changes can be made to the invention in light of theabove Detailed Description. While the above description details certainembodiments of the invention and describes the best mode contemplated,no matter how detailed the above appears in text, the invention can bepracticed in many ways. Details of the system may vary considerably inimplementation details, while still being encompassed by the inventiondisclosed herein. As noted above, particular terminology used whendescribing certain features or aspects of the invention should not betaken to imply that the terminology is being redefined herein to berestricted to any specific characteristics, features, or aspects of theinvention with which that terminology is associated. In general, theterms used in the following claims should not be construed to limit theinvention to the specific embodiments disclosed in the specification,unless the above Detailed Description section explicitly defines suchterms. Accordingly, the actual scope of the invention encompasses notonly the disclosed embodiments, but also all equivalent ways ofpracticing or implementing the invention under the claims.

While certain aspects of the invention are presented below in certainclaim forms, the inventors contemplate the various aspects of theinvention in any number of claim forms. For example, while only oneaspect of the invention is recited as embodied in a computer-readablemedium, other aspects may likewise be embodied in a computer-readablemedium. As another example, while only one aspect of the invention isrecited as a means-plus-function claim under 35 U.S.C. §112, sixthparagraph, other aspects may likewise be embodied as ameans-plus-function claim, or in other forms, such as being embodied ina computer-readable medium. (Any claims intended to be treated under 35U.S.C. §112, ¶6 will begin with the words “means for.”) Accordingly, theinventors reserve the right to add additional claims after filing theapplication to pursue such additional claim forms for other aspects ofthe invention.

We claim:
 1. A system for restoring a file from a storage device, thesystem comprising: at least one processor; at least one data storagedevice; means for receiving a request for a file, wherein the file isarchived as one or more data blocks on the storage device; means fordetermining a first file and a first offset within the first filecorresponding to the requested file, wherein the first file stores datablocks that are not eligible for single instancing, and wherein thefirst file also stores at least one data structure that includesreferences to data blocks that are eligible for single instancing; meansfor accessing the first file at the first offset; means for determiningif a first data block beginning at the first offset includes at least afirst portion of the requested file; means for obtaining the first datablock from the first file when the first data block beginning at thefirst offset includes at least the first portion of the requested file;and means for providing the requested file to a client device.
 2. Thesystem of claim 1, further comprising: means for storing in the datastructure of the first file a reference to the already stored instanceof the first data block if an instance of a second data block isreceived when the first data block has already been stored on thestorage device; and means for storing the second data block to a thirdfile if the second data block is received when an instance of the seconddata block has not already been stored on the storage device, whereinthe third file stores only a single instance of each data block, whereinthe third file stores data blocks from more than one file stored at oneor more computing client devices, and wherein the third file includesmultiple portions available for storing blocks, and wherein the seconddata block is stored in one or more portions.
 3. The system of claim 1,further comprising: means for determining if data beginning at the firstoffset includes a reference to a second data block in a second file thatincludes at least a second portion of the requested file; means foraccessing the second file when the data beginning at the first offsetincludes the reference to the second data block in the second file; andmeans for obtaining the second data block from the second file.
 4. Thesystem of claim 3, wherein the first file is located within a firstfolder, and the second file is located within a second folder.
 5. Thesystem of claim 1, further comprising: determining a logical containercorresponding to the requested file; and analyzing the logical containerto determine the first file.
 6. The system of claim 1, furthercomprising: accessing an index file associated with the first file,wherein the index file stores, for at least some of the one or more datablocks, a single flag indicating whether the stored block of data isreferred to in one or more metadata files on the one or more storagedevices; and analyzing the index file to determine the first offsetwithin the first file.
 7. A computer-readable storage medium whosecontents cause a computing system to perform a method of restoring afile from a storage device, the method comprising: receiving a requestfor a file, wherein the file is archived as one or more data blocks onthe storage device; determining a first file and a first offset withinthe first file corresponding to the requested file; accessing the firstfile at the first offset; determining if a first data block beginning atthe first offset includes at least a first portion of the requestedfile; when the first data block beginning at the first offset includesat least the first portion of the requested file, obtaining the firstdata block from the first file; when a second data block that includesat least a second portion of the requested file exists, obtaining thesecond data block; and providing the requested file to a client device.8. The computer-readable storage medium of claim 7, wherein the methodfurther comprises: determining if data beginning at the first offsetincludes a reference to a second data block in a second file thatincludes at least a second portion of the requested file; and when thedata beginning at the first offset includes the reference to the seconddata block in the second file, accessing the second file; and obtainingthe second data block from the second file.
 9. The computer-readablestorage medium of claim 7, wherein the method further comprises: when asecond portion of the requested file is in a second file, determining asecond offset within the second file at which the second data block islocated; and obtaining the second data block.
 10. The computer-readablestorage medium of claim 7, wherein the first file is located within afirst folder, and the second file is located within a second folder. 11.The computer-readable storage medium of claim 7, wherein the methodfurther comprises: determining a logical container corresponding to therequested file; and analyzing the logical container to determine thefirst file.
 12. The computer-readable storage medium of claim 7, whereinthe method further comprises: accessing an index file associated withthe first file; and analyzing the index file to determine the firstoffset within the first file.
 13. A method of restoring a file from astorage device, the method comprising: receiving a request for a file,wherein the file is archived as one or more data blocks on the storagedevice; determining a first file and a first offset within the firstfile corresponding to the requested file; accessing the first file atthe first offset; determining if a first data block beginning at thefirst offset includes at least a first portion of the requested file;when the first data block beginning at the first offset includes atleast the first portion of the requested file, obtaining the first datablock from the first file; when a second data block that includes atleast a second portion of the requested file exists, obtaining thesecond data block; and providing the requested file to a client device.14. The method of claim 13, wherein the method further comprises:determining if data beginning at the first offset includes a referenceto a second data block in a second file that includes at least a secondportion of the requested file; and when the data beginning at the firstoffset includes the reference to the second data block in the secondfile, accessing the second file; and obtaining the second data blockfrom the second file.
 15. The method of claim 13, wherein the methodfurther comprises: when a second portion of the requested file is in asecond file, determining a second offset within the second file at whichthe second data block is located; and obtaining the second data block.16. The method of claim 13, wherein the first file is located within afirst folder, and the second file is located within a second folder. 17.The method of claim 13, wherein the method further comprises:determining a logical container corresponding to the requested file; andanalyzing the logical container to determine the first file.
 18. Themethod of claim 13, wherein the method further comprises: accessing anindex file associated with the first file; and analyzing the index fileto determine the first offset within the first file.
 19. The method ofclaim 13, wherein determining a first file and a first offset within thefirst file corresponding to the requested file includes analyzing anindex file to determine a volume folder and chunk folder that includethe data blocks associated with the requested file.
 20. The method ofclaim 13, wherein determining a first file and a first offset within thefirst file corresponding to the requested file includes determining avolume folder and chunk folder corresponding to the requested data.